Usm ndrray array protocol must raise#1964
Conversation
|
Deleted rendered PR docs from intelpython.github.com/dpctl, latest should be updated shortly. 🤞 |
|
Array API standard conformance tests for dpctl=0.19.0dev0=py310h93fe807_434 ran successfully. |
|
Array API standard conformance tests for dpctl=0.19.0dev0=py310h93fe807_435 ran successfully. |
|
Should we define copy and dtype parameters? NumPy claims it will raise warnings otherwise, but of course, this is just here to raise an error—not sure if it will be a problem or not. |
|
@ndgrigorian Could you please cite where sych claim is made? I looked at https://numpy.org/doc/stable/reference/generated/numpy.asarray.html and could not find it |
If you mean in the test, than we could, but it should not make a difference. |
https://numpy.org/doc/2.1/user/basics.interoperability.html#dunder-array-interface
|
8571abc to
f27d38f
Compare
|
I have changed |
|
Array API standard conformance tests for dpctl=0.19.0dev0=py310h93fe807_435 ran successfully. |
|
Array API standard conformance tests for dpctl=0.19.0dev0=py310h93fe807_436 ran successfully. |
The property raises TypeError informing user that implicit conversions from usm_ndarray to numpy.ndarray are not permitted. Explicit conversion using `dpctl.tensor.asnumpy` is advised. Disallowing implicit conversion prevents `np.asarray(usm_ar)` from creating an array of 0D usm_ndarray instances, because using it is very costly due to multitude of short-array transfers from GPU to host.
a9385af to
8393a75
Compare
|
Array API standard conformance tests for dpctl=0.19.0dev0=py310h93fe807_440 ran successfully. |
Implement
usm_ndarray.__array__that raisesTypeErrorto disallow implicit conversion ofusm_ndarraytonumpy.ndarraywithdtype=object.